Enhancements
************

Like all software, the font utilities can all be (probably endlessly) improved.  Following are some possible projects.

If you would like to contribute, send mail to bug-gnu-utils@prep.ai.mit.edu first, so we can coordinate the work.

Additional fonts
================

The original purpose of these programs was to create fonts for Ghostscript, the GNU PostScript-compatible interpreter written by Peter Deutsch.  Adobe and many other vendors sell fonts which Ghostscript can use, but they place many restrictions on the use of those fonts.  These restrictions certainly include modification and copying; in some cases, they even include using the font on more than one printer or display! These restrictions are contrary to the aims of the GNU project.

Obviously we cannot compete in volume with Adobe, Bitstream, or other vendors, all of whom probably have dozens if not hundreds of people working on nothing but font production, and additional people hired as programmers in support.  The present authors (both working half-time) are the entire FSF ``font production'' department, both for design and for programming.

Fortunately, we do not need to compete in volume (certainly we haven't needed the thousands of Adobe fonts in our practice as typographers). Our aim is to produce the basic typefaces for typography: Garamond, Bodoni, Gill Sans, Univers, Baskerville, and perhaps a few others.  If someone wants some other typeface, they could use our programs to make it, and, we hope, contribute it back to GNU for others to use.

We do need volunteers to help create fonts for the GNU project.  You do not need to be an expert type designer to help, but you do need to know enough about TeX and/or PostScript to be able to install and test new fonts.  Example: if you know neither (1) the purpose of TeX utility program gftopk nor (2) what the PostScript scalefont command does, you probably need more experience before you can help.

If you can volunteer, the first step is to compile the font utilities (see Installation).  After that, contact us at karl@gnu.ai.mit.edu.  I will get you a scanned type specimen image.  See Creating fonts, for how to use these utilities to turn that into a font you can use in TeX or PostScript.

Legal issues
------------

This section owes a great deal to Charles Bigelow (co-designer with Kris Holmes of the Lucida typeface family), who has generously answered our many queries about fonts and the law around the world with remarkable patience and understanding.  (But he is naturally not responsible for any errors here, much less our opinions.)

Fonts have always been treated rather strangely under the law, as befits their rather strange nature: letterforms are indivisibly both useful and artistic.  In most countries, and in all countries until recently, utility has taken precedence; i.e., it has been legal to copy fonts without permission or fee (the sitation that the Free Software Foundation hopes will obtain for software).

In any case, to the best of our knowledge, the situation in those countries which have any sort of typeface protection is as follows:

United States
     Typeface designs can be patented, but not copyrighted.  Only a few designs have been patented.  (Lucida and Stone are the only ones we know of.  We don't know what the grounds were for patenting Stone, but Lucida had some novel features in its design which make it reasonable to patent, if one accepts the patent system in the first place.)

     Particular programs which instantiate a font can be copyrighted just as any other computer program can.  This is arguably wrong, since font programs are nothing but a description of the shapes, possibly with some simple hints, and there's only one basic way to describe the shapes in any given language.  Thus, the creativity lies in making the shape right, not in making the computer program right, so it would seem that to be consistent, the copyright laws should protect the design, not the program---the opposite of the current situation.

Germany
     Typeface designs have been copyrightable as original works of art since 1981.  The law passed then was not retroactive, however, German courts have upheld the intellectual property rights of font designers even for earlier cases.  In one case the heirs of Paul Bauer (designer of Futura) sued the Bauer foundry for arbitrarily discontinuing a portion of their royalties, and won.

     Since 1981, many (perhaps most) designs have been copyrighted in Germany.

England
     A copyright law passed in 1989 covers typeface designs first published in England (or published in Britain within 30 days of its publication elsewhere), and it is (unbelievably foolishly) retroactive.  It's unclear how far back the law extends, but Times Roman, designed in the late 1920's and 1930's by Stanley Morison and cut by Victor Lardent for Monotype is probably covered.  This does not mean GNU cannot have a Times Roman; it just means we cannot start with an English version, as the law does not forbid importing foreign versions of English typefaces.

France
     The Romain du Roi typeface designed by Philippe Grandjean in 1702 for the French royal family is protected, and perhaps other such ``royal'' designs.  Since these are not widely used anyway, it's not important that GNU provide them.

In 1973 the international Vienna treaty on typeface design protection was proposed.  France ratified it in 1974 or 1975, and Germany in 1981. The English law might constitute ratification, but this has not been settled.  In any case, since at least four countries have to ratify it before it takes effect (and even then it takes effect only in those countries which ratify it), it is still of no consequence for now.

Program features
================

Here are some possible projects:

BZRedit

       * Rewrite as a C program along the lines of XBfe.

       * Add support for hints.

BZRto

       * Output more font formats, e.g., TrueType.

       * Output hints for Metafont and Type 1 fonts.

       * Make better guesses for the FontInfo information.

       * Handle obliquing fonts by changing the transform matrix in the output, instead of changing the numbers in the splines.

       * Do nonlinear scaling.

       * Handle italic corrections in the Metafont output somehow.  Probably have to do the same in Charspace.

Fontconvert

       * Output virtual fonts as an option, instead of another bitmap font.

       * Allow specifying entire input encodings and output encodings (the same .enc files that the other programs read).

GF library

       * Support multiple simultaneous open fonts, like the PK library does now.

       * Output a checksum.

GSrenderfont

       * Allow for characters larger than 1 inch square in the original font.

       * Implement slanting, extending, and small caps, a la Dvips.

Imageto

       * Recognize more image formats, e.g., Tiff.

       * Perhaps the -column-split option in Fontconvert should be removed, and the equivalent information specified in the IFI file.

IMGrotate

       * Perhaps combine with Imageto.

       * Implement a good rotation algorithm, perhaps as described in: ``A Fast Algorithm for General Raster Rotation'', by Alan Paeth, Graphics Interface '86, pages 77--81.  (We'd be interested in hearing of optimized alternatives for the case of 90 degree rotation only).  The program pnmrotate, which mentions that article, in the PBMplus distribution could perhaps be adapted.

lib

       * Extend the encoding files to allow defining math attributes, probably by rewriting the parsing routines as a Bison grammar.

       * Write a variant of string_to_bitmap (in font.c) which understands kerns and ligatures.

       * Add support for BDF or other bitmap formats.  Unrelated utility programs now exist for handling the X11 BDF format (specifically, Bdf2gf and GFto), but it might be useful to integrate BDF support.

Limn
     Handle the standard X toolkit options.

PK library
     Implement output of PK files.

TFM library

       * Support multiple simultaneous open fonts, like PK does now.

       * Support ligatures in their full generality.

       * Output a checksum.

XBfe

       * Allow showing more than one character at a time.

       * Adjusting (or at least seeing) the baseline, cap height, x-height, or arbitrary guidelines.

       * Handle multiple fonts.

       * Notice if the window it's given is too small, and give up.

       * Ask the window manager for a window big enough for the largest character in the font, not the first character.

In addition, one general enhancement would be to allow more than 256 characters per font.  The bitmap formats allow this already, and the TFM format has some support for it.

Two other smaller general improvements: combine multiple -range options; allow for omitting ranges.

Portability
===========

We didn't worry about making the programs work with any C compiler; instead, we used GNU C extensions where they were useful.  Likewise for GNU make.

We allowed ourselves this luxury because these programs are not historical utilities which people would expect to find on any Unix system.  Rather, they are application programs.  Perhaps having them work only with other GNU programs will encourage people to switch to GNU programs, or at least become aware of them.

It probably would not be too hard to change the programs to work with other ANSI C compilers.  Changing them to work with old C compilers would be more painful.  Thus far, the dependency on GCC hasn't proved a serious problem, because GCC runs on so many machines.

It would be dull but straightforward to write Makefiles for the programs which didn't use any of GNU make's special features.  As with GCC, though, GNU make is so widely available that we haven't felt it necessary to do so.

The one exception is to this are the dozen or so files in the lib and include directories which implement the path searching algorithm.  Because these files are shared with the TeX, Dvips, and XDvi distributions, they are written to work with old C compilers.

See Archives, for information on how to obtain GCC and the other programs mentioned.  See Portability as it applies to GNU (GNU Coding Standards), for more discussion of the portability of GNU programs in general.

Implementation
==============

This section describes some of the conventions we used in the organization of the source code.  See GNU Coding Standards, for the general GNU conventions.

In our sources, .c files include config.h first, which in turn includes global.h, which includes types.h and other header files which define ubiquitous identifiers.

.h files, on the other hand, do not include config.h. They only include whatever headers are needed to define what they themselves use---typically including but not limited to types.h.

All .h files are protected with #ifndef UNIQUE-SYMBOL.

The upshot of these conventions is that headers can be included in any order, as many times as necessary.  In a .c file, only those headers which define symbols needed in the C source need be included, without worrying that some headers depend on others.  (ANSI C defines its headers to follow these same rules.)

Virtually all .c files---the only exceptions are (sometimes) main.c and some library files---have a corresponding .h file, which defines all the public symbols (e.g., non-static routines and types). in the .h file are intended to explain the external interface; comments in the .c file assume you already know what's in the .h file, to avoid having the same information in two places, and try to explain only implementation details.

Therefore, a .c file should always include its corresponding .h file, to ensure consistency between the definitions and the declarations.  GCC 2's -Wmissing-prototypes option can be used to check this.

The main program is always in a file named main.c.  Typically it loops through all the characters in the input font, doing something with them.  Parsing arguments is also done in main.c, in a function named read_command_line, using getopt.  See Command-line options, for more information on option parsing.

The configure script used to determine system dependencies is generated by GNU Autoconf from configure.in.  When configure runs, it creates include/c-auto.h from include/c-auto.h.in to record what it discovers.  config.h includes this file.

We access members of most structure types via macros instead of with . or -> directly.  We pass and return whole structures without hesitation; this has not resulted in any noticeable performance loss.  When we use pointers to structures, it's almost always because we need a distinguishable value (i.e., NULL).

When a function has no side effects (e.g., assignments to global variables), and does not examine any values except its arguments (e.g. if a pointer is passed, it does not examine the data pointed to), we declare it const.  (This is a GNU C extension.)